4-3 葵花宝典：什么是依赖注入(DI)&控制反转IoC
1. IoC/DI核心概念
1.1 基本定义
IoC (控制反转)
控制反转（Inversion of Control）是面向对象编程中的一种设计原则，其核心思想是将对象的创建和依赖关系的管理从类内部转移到外部容器。传统编程中，对象通常自己控制依赖的创建和管理，而IoC则将这一控制权“反转”给外部框架或容器。
通俗理解：
- 传统方式：类自己“主动”创建依赖对象（如
new Service()）。 - IoC方式：类“被动”接收依赖对象（由容器注入）。
示例：
// 传统方式（强耦合）
class UserService {
private db = new Database(); // 直接创建依赖
}
// IoC方式（解耦）
class UserService {
constructor(private db: Database) {} // 依赖由外部注入
}
typescript
DI (依赖注入)
依赖注入（Dependency Injection）是IoC的具体实现模式，通过构造函数、属性或方法将依赖对象注入到类中。DI的核心目标是解耦，使类不再直接依赖具体实现，而是依赖抽象（如接口）。
三种注入方式：
- 构造函数注入（最常用）：
class UserService { constructor(private db: Database) {} }typescript - 属性注入：
class UserService { @Inject() private db: Database; }typescript - 方法注入：
class UserService { setDatabase(db: Database) { this.db = db; } }typescript
核心关系
💡 设计原则指导实现方式：IoC是思想，DI是落地手段。其他实现方式还包括服务定位器（Service Locator），但DI更符合现代框架的设计趋势。
1.2 关键价值
✅ 降低模块耦合度
- 问题：传统代码中，类直接依赖具体实现（如
new Database()），更换依赖需修改源码。 - 解决：通过DI，类仅依赖接口，具体实现由外部注入。
interface IDatabase { save(data: string): void; } class UserService { constructor(private db: IDatabase) {} // 依赖抽象 }typescript
效果：更换数据库实现（如从MySQL切到MongoDB）只需修改注入的实例，无需改动UserService。
✅ 提升代码可测试性
- Mock测试：通过注入模拟对象（Mock）替代真实依赖，轻松实现单元测试。
const mockDB = { save: jest.fn() }; const service = new UserService(mockDB); // 注入Mock service.saveUser("test"); expect(mockDB.save).toBeCalledWith("test");typescript
✅ 增强系统扩展性
- 开闭原则：系统扩展时无需修改已有代码，只需新增实现类并注入。
案例：支持多数据库驱动：class MySQLDatabase implements IDatabase { ... } class MongoDB implements IDatabase { ... } // 使用时按需注入 const service1 = new UserService(new MySQLDatabase()); const service2 = new UserService(new MongoDB());typescript
✅ 符合开闭原则
- 开放：通过新增类扩展功能（如新增
PostgreSQLDatabase）。 - 关闭：无需修改现有类（如
UserService保持不变）。
1.3 扩展知识：IoC容器
现代框架（如NestJS、Spring）通过IoC容器自动化管理依赖注入：
- 注册依赖：声明哪些类可被注入。
@Injectable() class Database { ... }typescript - 自动装配：容器自动解析依赖链并注入。
@Injectable() class UserService { constructor(private db: Database) {} // 容器自动注入Database实例 }typescript - 生命周期管理：单例（Singleton）、瞬态（Transient）等模式。
💡 思考题：
- 如果
Database依赖ConfigService，IoC容器如何解决多层依赖？ - 循环依赖（如A依赖B，B依赖A）该如何处理？
1.4 常见问题解答（FAQ）
Q1：IoC和DI有什么区别？
- IoC是设计思想（控制权反转），DI是实现方式（依赖注入）。
Q2：为什么不用Service Locator模式？
- Service Locator需主动查找依赖（如
container.get('db')），隐藏了依赖关系，而DI通过参数显式声明依赖，更易维护。
Q3：DI会导致性能问题吗？
- 现代框架（如NestJS）在启动时完成依赖解析，运行时无额外开销。反射（如
reflect-metadata）可能轻微影响启动速度。
1.5 延伸学习
- 推荐阅读：
- 动手实验：
使用reflect-metadata实现简易DI容器，支持构造函数注入和单例模式。
通过本节学习，你已掌握IoC/DI的核心思想与价值。接下来，尝试在项目中用DI替换强依赖代码，体验解耦带来的灵活性！ 🚀
2. 强依赖问题示例
2.1 问题代码
class iPhone {
playGame(name: string) {
console.log(`${name}正在用iPhone玩游戏`);
}
}
class Student {
private phone: iPhone = new iPhone(); // 强依赖具体实现
play() {
this.phone.playGame("学生");
}
}
typescript
代码解析：
- 强依赖关系：
Student类直接实例化iPhone对象，形成了对具体实现的硬编码依赖。 - 紧耦合：
Student类的play方法完全依赖于iPhone类的playGame方法实现。
2.2 问题分析
1. 违反开闭原则（OCP）
- 问题：当需要更换手机类型时（如从iPhone换成Android），必须修改
Student类的源代码。 - 示例场景：
// 如果需要支持Android，必须修改Student类： class Student { private phone: Android = new Android(); // 直接修改源码 play() { this.phone.playGame("学生"); } }typescript - 后果：每次需求变更都需要修改已有代码，增加维护成本。
2. 难以扩展
- 问题：无法灵活支持新的设备类型（如iPad、华为手机等）。
- 扩展性对比：
设计方式 新增设备类型 修改点 强依赖 必须修改 Student类高侵入性 依赖注入 新增类并实现接口 无需修改 Student类
3. 测试困难
- 问题：无法在单元测试中替换
iPhone为Mock对象。 - 测试场景：
// 理想测试（使用Mock）： const mockPhone = { playGame: jest.fn() }; const student = new Student(mockPhone); // 但强依赖无法注入Mock student.play(); expect(mockPhone.playGame).toBeCalledWith("学生");typescript - 后果：只能进行集成测试，无法隔离测试
Student的逻辑。
4. 其他潜在问题
- 复用性差：
Student类无法在其他项目中使用（除非其他项目也依赖iPhone类）。 - 团队协作冲突：多人修改同一类时容易产生代码冲突。
2.3 问题可视化
2.4 解决方案对比
| 问题 | 强依赖模式 | 依赖注入模式 |
|---|---|---|
| 开闭原则 | 违反（需修改源码） | 符合（扩展新类即可） |
| 扩展性 | 差（硬编码实现） | 好（面向接口编程） |
| 可测试性 | 困难（无法Mock） | 简单（轻松注入测试替身） |
| 团队协作 | 易冲突（修改集中） | 低风险（职责分离） |
2.5 实战改进建议
- 第一步：抽象接口
interface IPhone { playGame(name: string): void; }typescript - 第二步：改造Student类
class Student { constructor(private phone: IPhone) {} // 依赖注入 play() { this.phone.playGame("学生"); } }typescript - 第三步：自由扩展
class Android implements IPhone { playGame(name: string) { console.log(`${name}用Android玩游戏`); } } // 使用时按需注入 const student1 = new Student(new iPhone()); const student2 = new Student(new Android());typescript
2.6 思考题
- 如果
playGame方法需要增加参数（如游戏类型），强依赖模式和DI模式分别需要修改哪些地方？ - 在微服务架构中，强依赖会引发哪些更严重的问题？
通过这个案例，可以清晰看到强依赖对软件质量的破坏性。依赖注入不仅是技术选择，更是工程实践的必选项。 🛠️
3. 依赖注入解决方案
3.1 接口抽象
interface Phone {
playGame(name: string): void;
// 可以扩展更多通用方法
takePhoto?(): void; // 可选方法
call?(number: string): void;
}
typescript
设计要点：
- 接口定义行为契约，不关心具体实现
- 使用
?标记可选方法，增加灵活性 - 符合接口隔离原则(ISP)，避免"胖接口"
扩展思考：
- 如何设计跨平台的通用设备接口？
- 接口版本升级时如何保证向后兼容？
3.2 实现具体类
// iPhone实现
class iPhone implements Phone {
private readonly os = "iOS";
playGame(name: string) {
console.log(`${name}用${this.os}设备玩游戏`);
}
takePhoto() {
console.log("用1200万像素摄像头拍照");
}
}
// Android实现
class Android implements Phone {
constructor(private brand: string) {} // 支持不同品牌
playGame(name: string) {
console.log(`${name}用${this.brand}手机玩游戏`);
}
call(number: string) {
console.log(`用5G网络拨打${number}`);
}
}
// 华为平板实现
class HuaweiPad implements Phone {
playGame(name: string) {
console.log(`${name}用鸿蒙平板玩游戏`);
}
}
typescript
最佳实践：
- 实现类可以扩展接口未定义的特有功能
- 通过构造函数参数支持差异化配置
- 保持单一职责原则(SRP)，每个类只做一件事
3.3 依赖注入实现
// 增强版DIStudent
class DIStudent {
constructor(
private phone: Phone,
private gameType?: string // 额外依赖项
) {}
play(name: string) {
if(this.gameType) {
console.log(`游戏类型：${this.gameType}`);
}
this.phone.playGame(name);
}
// 支持方法注入
changeDevice(phone: Phone) {
this.phone = phone;
}
}
// 使用示例
const devices = {
iphone: new iPhone(),
huawei: new Android("华为"),
pad: new HuaweiPad()
};
const student = new DIStudent(devices.iphone, "MOBA");
student.play("张三"); // 输出：游戏类型：MOBA \n 张三用iOS设备玩游戏
student.changeDevice(devices.huawei);
student.play("李四"); // 输出：李四用华为手机玩游戏
typescript
高级技巧：
- 混合使用构造函数注入和方法注入
- 通过对象字面量管理依赖实例
- 支持可选依赖项(如gameType)
3.4 优势对比
| 特性 | 强依赖模式 | DI模式 | 现实案例 |
|---|---|---|---|
| 耦合度 | 类与实现硬绑定 | 仅依赖抽象接口 | 更换数据库驱动无需修改业务代码 |
| 扩展性 | 需修改多处源码 | 新增类即可 | 快速支持新的支付渠道 |
| 可测试性 | 必须启动真实依赖 | 可注入Mock对象 | 单元测试无需连接真实数据库 |
| 设计原则 | 违反开闭/依赖倒置原则 | 符合SOLID原则 | 框架生态的基础设计 |
| 团队协作 | 容易产生代码冲突 | 并行开发互不干扰 | 微服务团队独立开发 |
3.5 设计模式结合
工厂模式+DI：
class PhoneFactory {
static create(type: string): Phone {
switch(type) {
case "iphone": return new iPhone();
case "android": return new Android("小米");
default: throw new Error("不支持的设备类型");
}
}
}
const student = new DIStudent(PhoneFactory.create("android"));
typescript
装饰器模式+DI：
class LoggablePhone implements Phone {
constructor(private phone: Phone) {}
playGame(name: string) {
console.log(`[LOG] 开始游戏`);
this.phone.playGame(name);
console.log(`[LOG] 游戏结束`);
}
}
const student = new DIStudent(new LoggablePhone(new iPhone()));
typescript
3.6 常见问题解答
Q1：什么时候该用接口而不是抽象类？
- 需要多继承时用接口
- 需要包含部分实现时用抽象类
- TypeScript中优先选择接口(更轻量)
Q2：如何管理大量依赖项？
- 使用DI容器(如NestJS的Module)
- 分层注入(将相关依赖聚合为Service)
- 遵循单一职责原则
Q3：循环依赖怎么解决？
- 使用forwardRef延迟注入
- 重构代码消除循环
- 引入中介者模式
3.7 延伸学习
推荐实践：
- 在NestJS中实现分层DI
- 尝试用InversifyJS实现注解注入
- 阅读Spring框架的DI实现源码
性能优化：
- 对无状态依赖使用Singleton
- 避免在频繁调用的方法中注入
- 使用Tree-shaking减少打包体积
通过这个完整的DI解决方案，开发者可以获得：更高的代码灵活性、更好的可维护性、更高效的团队协作能力。现代前端框架如Angular/NestJS的核心机制正是基于这些原则构建的。 🚀
4. 控制反转原理
4.1 控制权转移
流程详解：
- 声明阶段：业务类通过构造函数参数/属性声明需要的依赖
- 注册阶段：配置源(如装饰器)告诉容器哪些类可被注入
- 解析阶段：容器构建完整的依赖关系图，处理循环依赖等问题
- 注入阶段：容器创建实例并注入所有依赖
- 运行阶段：业务类使用注入的依赖执行业务逻辑
典型案例：
- Angular的依赖注入系统
- Spring的ApplicationContext
- NestJS的Module系统
4.2 实现要素
1. 容器管理
生命周期管理策略：
| 生命周期 | 描述 | 适用场景 |
|---|---|---|
| Singleton | 整个应用共享一个实例 | 无状态服务/配置 |
| Transient | 每次注入创建新实例 | 有状态服务 |
| Request-scoped | 每个请求创建新实例(NestJS特有) | 请求相关的上下文数据 |
高级功能：
- 延迟加载(Lazy Loading)
- 条件注册(如
@Injectable({ scope: Scope.REQUEST })) - 生命周期钩子(如OnDestroy)
2. 依赖声明
声明方式对比：
// 方式1：装饰器(主流)
@Injectable()
class PhoneService {}
// 方式2：配置文件(Java Spring风格)
const config = {
providers: [PhoneService]
}
// 方式3：编码注册(灵活但繁琐)
container.register(PhoneService, { useClass: PhoneService });
typescript
类型系统集成：
// 利用TypeScript类型元数据
declare interface Type<T> extends Function {
new (...args: any[]): T;
}
class Container {
resolve<T>(target: Type<T>): T {
// 通过reflect-metadata获取参数类型
const paramTypes = Reflect.getMetadata('design:paramtypes', target);
// 递归解析依赖
return new target(...paramTypes.map(type => this.resolve(type)));
}
}
typescript
3. 自动装配
依赖解析算法：
- 构造器参数分析 → 2. 依赖关系拓扑排序 → 3. 循环依赖检测 → 4. 实例化顺序确定
异常处理：
try {
const service = container.resolve(StudentService);
} catch (error) {
if (error instanceof CircularDependencyError) {
// 处理循环依赖
}
if (error instanceof UnregisteredProviderError) {
// 处理未注册的依赖
}
}
typescript
4.3 高级特性
动态依赖
// 运行时决定实现类
container.register(Phone, {
useFactory: (config) => {
return config.isAppleUser ? new iPhone() : new Android();
},
inject: [ConfigService]
});
typescript
多实现绑定
// 命名绑定
container.register("PremiumPhone", { useClass: iPhonePro });
container.register("BudgetPhone", { useClass: RedmiPhone });
// 条件绑定
@Injectable()
class PaymentService {
constructor(
@Inject("PaymentGateway")
private gateway: IPaymentGateway
) {}
}
typescript
4.4 性能优化
启动优化：
- 预编译依赖关系图(Angular AOT)
- 使用DI令牌代替字符串标识(NestJS)
- 限制反射元数据的使用
运行时优化：
// 缓存单例实例
class Container {
private instances = new Map();
resolve<T>(target: Type<T>): T {
if (this.instances.has(target)) {
return this.instances.get(target);
}
const instance = //...创建实例
this.instances.set(target, instance);
return instance;
}
}
typescript
4.5 设计模式结合
策略模式+IoC：
interface SortStrategy {
sort(data: number[]): number[];
}
@Injectable()
class QuickSort implements SortStrategy { ... }
@Injectable()
class BubbleSort implements SortStrategy { ... }
@Injectable()
class Sorter {
constructor(private strategy: SortStrategy) {}
sort(data: number[]) {
return this.strategy.sort(data);
}
}
// 使用时动态注入策略
const sorter = container.resolve(Sorter); // 自动注入配置的策略
typescript
4.6 常见问题解答
Q1：IoC容器如何解决循环依赖？
- 方案1：使用属性注入代替构造器注入
- 方案2：引入中间层(如工厂模式)
- 方案3：框架级支持(如Angular的forwardRef)
Q2：应该在什么层级使用DI？
- 推荐在应用入口处集中配置
- 避免在UI组件/高频调用的工具类中滥用
Q3：如何调试依赖注入问题？
- 开启框架的调试模式(如NestJS的
NEST_DEBUG) - 可视化依赖关系图(如WebStorm的DI图表)
- 使用日志记录解析过程
4.7 延伸学习
推荐工具：
- InversifyJS：强大的TypeScript DI容器
- Awilix：轻量级Node.js DI解决方案
- Spring DI：Java经典实现
进阶课题：
- 研究DI在微服务架构中的应用
- 比较不同语言的DI实现差异
- 探索DI与函数式编程的结合
通过深入理解IoC容器的运作原理，开发者可以更好地驾驭现代前端框架，构建松耦合、易维护的应用程序架构。 💡
5. DI实现模式
5.1 三种注入方式
1. 构造函数注入（Constructor Injection）
代码示例：
class OrderService {
constructor(
private paymentService: PaymentService, // 必需依赖
@Optional() private logger?: Logger // 可选依赖
) {}
}
typescript
特点分析：
- ✅ 不可变性：依赖项通过
private修饰成为只读属性 - ✅ 显式声明：所有依赖在构造函数中一目了然
- ✅ 顺序保证：依赖初始化顺序与参数顺序一致
- ❌ 灵活性：所有依赖必须在实例化时提供
最佳实践：
- 标记非必需依赖为
@Optional() - 对基础服务（如数据库、配置）使用此方式
- 结合参数装饰器做验证：
constructor( @Inject('PaymentGateway') private paymentService: IPaymentService ) {}typescript
2. 属性注入（Property Injection）
代码示例：
class ShoppingCart {
@Inject()
private discountService!: DiscountService; // 非空断言
@Inject('Logger')
private logger?: Logger;
}
typescript
特点分析：
- ✅ 灵活性：可以在对象创建后设置依赖
- ✅ 可选性：更适合可选依赖项
- ❌ 时序风险：使用时需确保依赖已注入
- ❌ 隐蔽性：依赖关系不如构造函数明确
使用场景：
- 循环依赖解决方案
- 插件式架构中的可选功能
- 测试时动态替换依赖
框架支持对比：
| 框架 | 支持方式 | 典型用例 |
|---|---|---|
| Angular | @Inject()装饰器 | 注入ElementRef等平台相关对象 |
| Spring | @Autowired注解 | 注入JPA Repository |
| NestJS | @Inject()+可选令牌 | 跨模块服务注入 |
3. 方法注入（Method Injection）
代码示例：
class ReportGenerator {
private formatter?: DataFormatter;
@Inject()
setFormatter(formatter: DataFormatter) {
this.formatter = formatter;
}
generate() {
if (!this.formatter) throw new Error("未注入格式化工具");
// ...
}
}
typescript
特点分析：
- ✅ 动态性：运行时更换依赖实现
- ✅ 条件注入：可基于业务状态决定注入内容
- ❌ 复杂度：需要手动管理依赖有效性
- ❌ 时序控制：需确保方法调用顺序
高级模式：
- 结合工厂模式动态创建依赖
@Inject() setupService(@Inject('ServiceFactory') factory: ServiceFactory) { this.service = factory.create(config); }typescript
5.2 现代框架实现
NestJS深度剖析
核心机制：
@Module({
providers: [
{ provide: 'EmailService', useClass: SESEmailService }, // 接口绑定
{ provide: 'API_KEY', useValue: process.env.API_KEY }, // 值绑定
{
provide: 'PaymentGateway',
useFactory: (config: ConfigService) => { // 工厂函数
return config.isProd ? new Stripe() : new MockGateway();
},
inject: [ConfigService]
}
]
})
export class AppModule {}
typescript
创新特性：
- 作用域注入：支持请求级实例(
@Injectable({ scope: Scope.REQUEST })) - 自定义装饰器：简化特定场景注入
export const User = createParamDecorator( (data: string, ctx: ExecutionContext) => { const request = ctx.switchToHttp().getRequest(); return data ? request.user[data] : request.user; } );typescript
Angular进阶实践
分层注入器：
依赖解析规则：
- 从当前组件向上查找
- 模块级提供器优先于根提供器
- 使用
@Host()限定查找范围
性能优化技巧：
providedIn: 'root'vs 模块级提供器- 使用
InjectionToken代替字符串令牌 - 懒加载模块的依赖隔离
Spring企业级方案
配置方式演进：
// XML配置(传统)
<bean id="userService" class="com.example.UserService">
<property name="userDao" ref="userDao"/>
</bean>
// JavaConfig(现代)
@Configuration
public class AppConfig {
@Bean
public UserService userService(UserDao userDao) {
return new UserService(userDao);
}
}
java
高级特性：
- 条件装配：
@ConditionalOnProperty - 生命周期回调：
@PostConstruct,@PreDestroy - AOP集成：
@Aspect代理注入
5.3 模式选择决策树
5.4 前沿发展趋势
- 函数式DI：
// 利用闭包实现轻量DI const createUserService = (deps: ServiceDeps) => () => ({ login: (cred) => deps.auth(cred) });typescript - 编译时注入：
- Angular的AOT编译优化
- TypeScript装饰器元数据预生成
- Serverless适配：
// AWS Lambda场景 export const handler = diContainer.resolve(LambdaHandler);typescript
5.5 常见陷阱规避
- 循环依赖反模式：
- 问题：A→B→C→A
- 解决：引入中间服务/改为方法注入
- 过度注入：
- 症状：构造函数参数超过5个
- 重构：引入聚合服务/领域事件
- 作用域混淆：
- 错误：在Singleton中注入Request-scoped服务
- 修正：使用代理模式/Lazy注入
5.6 性能基准对比
| 注入方式 | 初始化耗时 | 内存占用 | 适用场景 |
|---|---|---|---|
| 构造函数注入 | 低 | 低 | 高频使用基础服务 |
| 属性注入 | 中 | 中 | 可选插件功能 |
| 方法注入 | 高 | 高 | 运行时策略切换 |
通过全面理解各种DI实现模式，开发者可以根据具体场景选择最优方案，构建既灵活又健壮的应用架构。 🌟
6. 反射实现DI
6.1 reflect-metadata基础
核心机制解析
import 'reflect-metadata';
// 使用Symbol创建唯一令牌
const PHONE_KEY = Symbol.for('PHONE_INTERFACE');
// 类装饰器存储元数据
@Injectable()
class iPhone {
playGame() {
console.log("Playing on iPhone");
}
}
// 属性装饰器实现注入
class Student {
@Inject(PHONE_KEY)
private phone!: Phone; // 非空断言
play() {
this.phone.playGame();
}
}
typescript
关键技术点：
- 元数据存储：通过
Reflect.defineMetadata将类信息存入：Reflect.defineMetadata('design:paramtypes', [Phone], Student);typescript - 装饰器协同：
@Injectable标记可注入类@Inject指定具体依赖令牌
- 类型安全：结合TypeScript的接口和抽象类：
interface Phone { playGame(): void; }typescript
调试技巧：
// 查看类的元数据
console.log(Reflect.getMetadata('design:paramtypes', Student));
// 输出：[ [Function: iPhone] ]
typescript
6.2 简易DI容器
增强版容器实现
class Container {
private static instances = new Map<symbol, any>();
// 注册依赖（支持三种绑定方式）
static register(token: symbol, provider: {
useClass?: new () => any,
useValue?: any,
useFactory?: () => any
}) {
if (provider.useClass) {
Reflect.defineMetadata(token, provider.useClass, token);
} else if (provider.useValue) {
this.instances.set(token, provider.useValue);
} else if (provider.useFactory) {
this.instances.set(token, provider.useFactory());
}
}
// 解析依赖（支持递归注入）
static resolve<T>(token: symbol): T {
if (this.instances.has(token)) {
return this.instances.get(token);
}
const target = Reflect.getMetadata(token, token);
if (!target) throw new Error(`未注册的依赖: ${token.toString()}`);
// 获取构造函数参数类型
const paramTypes = Reflect.getMetadata('design:paramtypes', target) || [];
const dependencies = paramTypes.map((t: any) => {
const depToken = Symbol.for(t.name);
return this.resolve(depToken);
});
const instance = new target(...dependencies);
this.instances.set(token, instance);
return instance;
}
}
typescript
使用场景示例
// 1. 注册依赖
Container.register(PHONE_KEY, { useClass: iPhone });
Container.register('GAME_SERVICE', {
useFactory: () => new GameService('RPG')
});
// 2. 自动装配
class GameCenter {
constructor(
@Inject(PHONE_KEY) private phone: Phone,
@Inject('GAME_SERVICE') private game: GameService
) {}
}
// 3. 获取实例
const center = Container.resolve<GameCenter>(Symbol.for('GameCenter'));
typescript
6.3 高级特性实现
循环依赖解决方案
class Container {
private static resolving = new Set<symbol>();
static resolve<T>(token: symbol): T {
if (this.resolving.has(token)) {
throw new Error(`检测到循环依赖: ${token.toString()}`);
}
this.resolving.add(token);
try {
// ...原有解析逻辑
} finally {
this.resolving.delete(token);
}
}
}
typescript
生命周期控制
enum Lifecycle {
Singleton,
Transient
}
static register(token: symbol, provider: {
useClass: new () => any,
lifecycle?: Lifecycle
}) {
if (provider.lifecycle === Lifecycle.Transient) {
Reflect.defineMetadata('transient', true, token);
}
// ...
}
typescript
6.4 与框架的对比
| 特性 | 手动反射实现 | NestJS | Angular |
|---|---|---|---|
| 循环依赖处理 | 需手动检测 | 自动抛出异常 | 分层注入器规避 |
| 作用域管理 | 需自行实现 | 内置请求/单例作用域 | 模块/组件作用域 |
| AOT支持 | 不支持 | 完全支持 | 完全支持 |
| 性能开销 | 较高（运行时反射） | 中等（预编译优化） | 低（编译时处理） |
6.5 最佳实践建议
- 生产环境方案：
- 使用成熟的DI框架（如NestJS）
- 仅在需要动态插件的场景使用手动DI
- 调试技巧：
// 打印完整的依赖图 console.log(Reflect.getMetadataKeys(Container));typescript - 安全限制：
- 禁止在浏览器环境使用
reflect-metadata（包体积过大） - 对敏感服务添加权限检查：
@Inject() set database(@Authorize('admin') db: Database) {}typescript
- 禁止在浏览器环境使用
6.6 延伸学习
推荐工具链：
- tsyringe：微软开发的轻量级DI容器
- injection-js：Angular的DI核心抽离版
进阶课题：
- 实现基于Decorator的AOP拦截器
- 研究WebAssembly中的DI方案
- 探索GraphQL Resolver中的依赖注入
通过深入理解反射式DI的实现原理，开发者可以更好地：
- 定制适合特定场景的DI方案
- 优化现有框架的DI性能
- 处理复杂的依赖关系管理需求 🛠️
7. 课后作业
1. 实现基于reflect-metadata的注解注入
任务要求：
- 使用
reflect-metadata实现@Injectable和@Inject装饰器 - 支持构造函数参数注入和属性注入
- 通过单元测试验证功能
参考实现：
// inject.ts
import 'reflect-metadata';
const INJECT_TOKEN = Symbol('INJECT_TOKEN');
// 类装饰器
export function Injectable(): ClassDecorator {
return (target) => {
Reflect.defineMetadata(INJECT_TOKEN, true, target);
};
}
// 属性装饰器
export function Inject(token: symbol): PropertyDecorator {
return (target, key) => {
Reflect.defineMetadata(INJECT_TOKEN, token, target, key);
};
}
// 测试用例
@Injectable()
class AuthService {
login() { return 'logged_in'; }
}
class UserController {
@Inject(Symbol.for('AuthService'))
private auth!: AuthService;
}
typescript
验证方法：
console.log(Reflect.getMetadata(INJECT_TOKEN, UserController.prototype, 'auth'));
// 应输出: Symbol(AuthService)
typescript
2. 扩展DI容器支持循环依赖检测
实现方案：
class Container {
private static resolutionStack = new Set<symbol>();
static resolve<T>(token: symbol): T {
if (this.resolutionStack.has(token)) {
throw new Error(`循环依赖检测: ${token.toString()}`);
}
this.resolutionStack.add(token);
try {
// ...原有解析逻辑
} finally {
this.resolutionStack.delete(token);
}
}
}
typescript
测试用例：
// 循环依赖场景
class ServiceA {
constructor(@Inject(SERVICE_B_TOKEN) private b: ServiceB) {}
}
class ServiceB {
constructor(@Inject(SERVICE_A_TOKEN) private a: ServiceA) {}
}
// 应抛出错误
Container.resolve(SERVICE_A_TOKEN);
typescript
3. 在NestJS中创建跨模块服务注入示例
步骤说明：
- 创建共享模块
// shared.module.ts @Module({ providers: [LoggerService], exports: [LoggerService] }) export class SharedModule {}typescript - 在消费模块导入
// user.module.ts @Module({ imports: [SharedModule], controllers: [UserController] }) export class UserModule {} // user.controller.ts @Controller() export class UserController { constructor(private logger: LoggerService) {} }typescript
关键点：
- 使用
exports公开服务 - 确保模块依赖关系正确
4. 尝试实现方法注入的装饰器版本
解决方案：
export function InjectMethod(token: symbol): MethodDecorator {
return (target, key, descriptor) => {
const originalMethod = descriptor.value;
descriptor.value = function (...args: any[]) {
const service = Container.resolve(token);
return originalMethod.apply(this, [service, ...args]);
};
};
}
// 使用示例
class PaymentProcessor {
@InjectMethod(PAYMENT_GATEWAY_TOKEN)
pay(service: PaymentGateway, amount: number) {
return service.charge(amount);
}
}
typescript
扩展学习资源
推荐阅读：
- Martin Fowler的DI论文（必读）
- 《Dependency Injection Principles, Practices, and Patterns》书籍
- NestJS官方文档的DI章节
前沿技术：
- 云原生环境下的DI实践（如Serverless架构）
- Web Components中的依赖注入
- Deno运行时中的模块注入方案
作业提交要求
- 代码提交到GitHub仓库
- 包含完整的单元测试
- 使用TypeScript严格模式
- 为关键代码添加文档注释
评分标准：
| 项目 | 分值 | 要求 |
|---|---|---|
| 功能完整性 | 40 | 所有基础功能实现 |
| 代码质量 | 30 | 类型安全/可读性/测试覆盖率 |
| 创新性 | 20 | 实现1项扩展功能 |
| 文档完整性 | 10 | 包含README和API文档 |
通过本作业，你将深入掌握：
- 反射元数据的实战应用
- 复杂依赖关系的设计能力
- 现代框架的DI集成方法
- 装饰器的高级编程技巧
建议使用VSCode的调试功能逐步验证DI容器的解析过程，这将帮助你更直观地理解控制反转的运作机制。 🚀
↑